[client] Android - Pull fresh TUN settings on Android rebuild - #6991
[client] Android - Pull fresh TUN settings on Android rebuild#6991pappz wants to merge 2 commits into
Conversation
…g state The Android TUN rebuild consumed state pushed through notifications and a Java-side snapshot, and both sources were unreliable. The DNS search-domain notifier fired OnNetworkChanged with an empty string, which the rebuild handler treated as the new route list, so any search domain change rebuilt the TUN with zero routes and cut all tunnel traffic. The rebuild also reused the search domains cached at the last establish, so search domain updates never reached the TUN at runtime. Make the notification a pure trigger and let the Java side pull a fresh snapshot instead. Expose GetTunSettings on the Android SDK client: it returns the current TUN route ranges, derived on demand by the route manager from the client routes, the exit-node selection and the fake IP blocks, together with the DNS search domains. The route notifier keeps only its last-announced baseline to suppress triggers for unchanged syncs; the TUN route state is owned by the route manager. SearchDomains now locks the DNS server mutex since the pull arrives from a Java thread. Requires the matching android-client change that switches recreateTUN to the pull API.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Release artifactsBuilt for PR head
GHCR images (amd64)
This comment is updated by the Release workflow. Artifact links expire according to the workflow retention policy. |
…artup (#6992) Android startup opened a throwaway Sync stream to management before creating the TUN device, only to learn the initial routes, DNS config and the DNS feature flag. Server side this computed a full network map and broadcast a false connect/disconnect pair to every peer in the account on every Android start; client side it put a blocking network round trip on the critical startup path and failed the whole engine start when management was unreachable. None of its outputs are needed upfront anymore: the TUN is created empty and the first sync triggers a rebuild that pulls the fresh route and search domain state, the permanent DNS server starts with an empty config that the first sync populates, and the fake IP manager is created lazily when the DNS feature flag turns on. Remove readInitialSettings and its plumbing: the InitialRoutes and DNSFeatureFlag manager config fields, the android construction-time route setup, the initial-route bookkeeping in the notifiers and the now-unused GetNetworkMap client method.
|



Describe your changes
Pull fresh TUN settings on Android rebuild instead of push
The Android TUN rebuild consumed state pushed through notifications and a Java-side snapshot, and both sources were unreliable. The DNS search-domain notifier fired OnNetworkChanged with an empty string, which the rebuild handler treated as the new route list, so any search domain change rebuilt the TUN with zero routes and cut all tunnel traffic. The rebuild also reused the search domains cached at the last establish, so search domain updates never reached the TUN at runtime.
Make the notification a pure trigger and let the Java side pull a fresh snapshot instead. Expose GetTunSettings on the Android SDK client: it returns the current TUN route ranges, derived on demand by the route manager from the client routes, the exit-node selection and the fake IP blocks, together with the DNS search domains. The route notifier keeps only its last-announced baseline to suppress triggers for unchanged syncs; the TUN route state is owned by the route manager. SearchDomains now locks the DNS server mutex since the pull arrives from a Java thread.
Requires the matching android-client change that switches recreateTUN to the pull API.
Issue ticket number and link
Stack
Checklist
Documentation
Select exactly one:
Docs PR URL (required if "docs added" is checked)
Paste the PR link from https://github.com/netbirdio/docs here:
https://github.com/netbirdio/docs/pull/__